@andersonfrailey wrote:

The increase in tax liability seems odd to me given the increased deficits CBO has projected. I'd love to hear other's thoughts on this.

CBO upgraded both their actual and potential NGDP level path so some of this could be feedback into receipts.

@andersonfrailey said:

The increase in tax liability seems odd to me given the increased deficits CBO has projected. I'd love to hear other's thoughts on this.

Then @evtedeschi3 said:

CBO upgraded both their actual and potential NGDP level path so some of this could be feedback into receipts.

Yes, this is exactly correct. More real growth and/or higher inflation cause higher nominal GDP, and therefore, higher nominal incomes than in the earlier CBO projection. Higher nominal incomes imply higher tax revenue than implied by the earlier CBO projection.

@andersonfrailey, Shouldn't taxdata pull request #180 wait until you can generate new values for the cps_weights.csv.gz file? Seems inconsistent to update the growfactors.csv and puf_weights.csv.gz files, but not the cps_weights.csv.gz file.

When #145 is resolved, you will be able to generate a new cps_weights.csv.gz file, right?

@martinholmer asked:

When #145 is resolved, you will be able to generate a new cps_weights.csv.gz file, right?

Not entirely. The Fortran code in #145 will only create an MPS file, which can then be run by the MINOS linear programming model, which I don't have access to. But, now that I have all of the components that are using to create the CPS weights file I can rewrite everything in Python or Julia and will be able to generate a new cps_weights.csv.gz file.

@andersonfrailey, Can we wait on merging PR #180 until all the recent and pending changes to PUF and CPS data are incorporated into the next (0.20.2) release of Tax-Calculator. Then we can update the CBO projection and release another Tax-Calculator version (0.20.3) that has only those changes. Does this make sense?

@martinholmer, yes I can wait to merge this.

@andersonfrailey said about taxdata PR #180:

Yes, I can wait to merge this [until after Tax-Calculator 0.20.2 has been released].

Thanks. Let me make sure that even after you update PR #180 so it can be merged that the growfactors.csv values will change only for years 2015+. No changes in values for years before 2015, right? This is important.

@martinholmer correct. The latest CBO update begins in 2016 so the only changes we see should be from 2016 to 2027 and then we'll also be able to add 2028 projections.

@andersonfrailey said:

The latest CBO update begins in 2016 so the only changes we see should be from 2016 to 2027 and then we'll also be able to add 2028 projections.

But then why is there a change in the 2015 value of ABENEFITS in the growfactors.csv file?

@martinholmer that might've been a mistake on my end. I'll look into it as I update this PR.

I'm planning on passing this task to our new intern. Since this PR was originally opened SOI has also released new estimates. Does anyone have strong feelings about updating the CBO projections and SOI estimates in the same PR? I know we typically try and perform updates incrementally, but I believe that because these go hand-in-hand updating them together would be ok.

Also now that we can create our own weights for the CPS we can extend our extrapolations to 2028.

@martinholmer @MattHJensen

@andersonfrailey said:

I'm planning on passing this task to our new intern. Since this PR was originally opened SOI has also released new estimates. Does anyone have strong feelings about updating the CBO projections and SOI estimates in the same PR? I know we typically try and perform updates incrementally, but I believe that because these go hand-in-hand updating them together would be ok.

Also now that we can create our own weights for the CPS we can extend our extrapolations to 2028.

Combining the use of the two new projections (CBO's and SOI's) into one pull request seems reasonable.
What's the strategy for resolving all the merge conflicts?

@martinholmer I was thinking it would be easier if she just worked on a new PR and use this one as a reference.

@andersonfrailey said:

I was thinking it would be easier if she just worked on a new PR and use this one [#180] as a reference.

Sounds sensible.

@andersonfrailey, Is PR #180 obsolete now that PR #289 has been merged?

@martinholmer yes, closing.